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Abstract. Template and Preprocessor Metaprogramming are both well-known 
in the C++ community to have much in common with Functional Programming 
(FP). Recently, very few research threads on underpinning these commonali- 
ties have emerged to empower cross-development of C++ Metaprogramming 
(C++MP) and FP. Yet, self-contained real-world demonstrations on the common- 
alities which can truly exemplify the Functional nature of C++MP are very rare. 
In this paper, we provide such a demonstration with a running application which 
we program side-by-side: We develop a compile-time abstract datatype for Ra- 
tional Numbers in C++. We then present the equivalent Haskell runtime pro- 
gram to outline the FP techniques used. Expectably, our Haskell program is 
considerably more succinct than its C++ counterpart metaprogram. Earlier stud- 
ies spotting this relative brevity suggest methods for automated transformation 
of Haskell code into C++MP. This paper studies the impediments to suggest 
semi-automatic translation with a multiparadigm FP language like F#. 



1 Introduction 

In 1994, Unruh wrote a C++ program which was designed to emit some prime numbers 
as warning messages [20], These prime numbers were calculated at compile-time using 
techniques which are well-known in today's template metaprogramming. A year later, 
Veldhuizen introduced expression templates to the world of C++ metaprogramming 
[22], Austern's book [3] exemplified some commonalities between STL (the Generic 
Programming part of the 1998 C++ Standard [ ] library) and FP. Alexandrescu's book 
presented a tour de force of C++MP and was the first to explain some similarities be- 
tween that and FP. Fast growth of the Boost C++ libraries catered a handful of metapro- 
gramming libraries so well that Abrahams and Gurtovoy devoted their book [ ] to that. 
Recently, a new trend of FP-injection has started to emerge in the C++ commu- 
nity. All that is based on the common belief that C++MP is essentially FP but at the 
metaprogramming level. Yet, the limited references in support of that belief fit into two 
groups, neither of which suits a new C++ programmer wanting to delve into the topic: 
Ones which hardly scratch the surface by providing examples on say how to implement 
simple compile-time functions such as factorial. Or, sizeable manuals of the relevant 
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Boost libraries such as MPL[ ], Fusion[ ], Proto[l 1], and Preprocessor[ ]. Functional 
programmers approaching C++ to examine that belief face the same difficulty. 

What is missing is a self-contained real-world explanation of the FP techniques 
used in C++MP which is short and approachable on the one hand, and inclusive on the 
other. In this paper, we aim to fill that gap by showing the important bits of a compile- 
time abstract datatype representing Rational Numbers (Q) in C++. 3 Support for Q 
is so important that Rational is already a built-in type in HASKELL. Furthermore, in 
C++, Boost. Rational[ I 2] is a relatively old hand member of the Boost library. More to 
the point is that Boost. Ratio[ ] has also recently been added to the Boost library to 
support Rational arithmetics at compile-time. 

We do not aim to provide the most efficient or most facilitating implementation. In 
fact, both Rational of HASKELL and Boost.Ratio outperform our solution from several 
standpoints. None of the techniques we present are new either. We leverage our compile- 
time presentation for Q to demonstrate the FP techniques commonly used in C++MP 
So, we go as deep into the technical details as required by a minimalist comparison. 

On the other hand, with FP becoming more popular in the C++ community, attempts 
on automatic translation from HASKELL to C++ are also gaining gravity. For reasons 
that we explain in the conclusions, we believe that a bidirectional translation across 
HASKELL and C++ is more productive. Every now and then, we explore the subtle 
differences between the two implementations to discuss the impediments the respec- 
tive part may cause to automatic translation in either direction. Our list of explained 
impediments is summarised in the conclusions. 

A note on laziness is relevant here: C++ templates are lazy from many viewpoints. 
For example, most of the type-checking is delayed until instantiation. This is the basis 
of how Sipos et al. [ I ''] managed to implement compile-time infinite sequences in C++. 
However, as also alluded to by Sinkovics [16], although C++MP is a lazy FP language 
with selective strictness, eager template evaluation is often enforced predominantly. 
Namely, in practice, one can consider C++MP a strict FP language with selective lazi- 
ness. In the conclusion, we argue thus that translation between C++ metaprograms and 
F# programs works much better. Even though, we develop this paper on comparison be- 
tween Haskell and C++ for two reasons: Firstly, Haskell is a pure FP language and 
therefore better for showing correspondence with FP. Secondly, we aim to demonstrate 
the inadequacy of a uniparadigm FP language for facilitating C++MP via a thorough 
comparison with such a language - HASKELL in this case. 

In our implementation, we call our HASKELL algebraic datatype Fraction because 
Rational is already a built-in HASKELL type. On the contrary, we call our C++ abstract 
datatype Rational to give less grounds for name confusion. In this paper, we do not use 
the Ox features of C++. In particular, as opposed to the C++0x parameter pack token, 
ellipsis here is our informal representation of unimportant details. We will drop names- 
pace qualifiers (i.e., std : : and boost : :) throughout our C++ codes for brevity reasons. 
Due to space constraints, in our C++ codes, we use multiple common conventions for 
breaking long statements into multiple lines. For the same reason, when the readability 
is not particularly impinged, we make the code extra compact in common ways. 



3 For simplicity, in this paper, we do not distinguish between the Set-Theoretical notion of Ra- 
tional Numbers and our codes representing that for programming purposes. 
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This paper starts by reviewing the related work in Section 2. Then, we briefly in- 
troduce the relevant parts of C++ and FP in Section 3. A short account of the parts of 
Boost. MPL that we use is also given in this section. The most important part of this 
paper is Section 4. Here, we explain how to represent Q as an abstract datatype both at 
the metaprogramming level in C++ and the ordinary level in HASKELL. We compare 
the implementations to enumerate the impediments to automatic translation across the 
languages. A detailed discussion is provided in the Conclusion. 

2 Related Work 

Sipos et al. [1 l )] start by enumerating some similarities between template metaprogram- 
ming and FP. They then informally describe a method for systematically producing 
metafunctions out of functions written in the pure FP language Clean [13], They ad- 
vertise that their Evalo metafunction evaluates the produced metaprograms according 
to the operational semantics of Clean, which is provided by van Eekelen and de Mol 
[ ]. Whilst they do not formally present their operational semantics, their informal ex- 
planation of that suggests remarkable differences between the operational semantics of 
Clean and that of theirs. 
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Fig. 1. Function Application of Sipos et al. 



Clean inherits the (app) of Launchbury for lazy evaluation [ ]. Function appli- 
cation in the suggested operational semantics of Sipos et al. takes several forms as 
depicted in Figure 1. Their (@) is essentially the (app) rule of Launchbury. They also 
add (,£) for strict application. This mere addition makes equivalence of their opera- 
tional semantics and that of Clean questionable. It is noteworthy that the operational 
semantics of van Eekelen and de Mol [ ] suffers from increase of expressiveness upon 
evaluation of let-expressions [15], Counter-intuitively enough, in such an operational 
semantics, e^x is not proven to be observationally equivalent to x seq e x. Finally, their 
(bind) rule is simply to optionally postpone function application. 

Sinkovics [ ] offers certain solutions for improving the FP support in MPL and 
discusses why they are needed. Sinkovics and Porkolab [ ] advertise implementation 
of a A -expression library on top of the operational semantics of Sipos et al. for embed- 
ded FP in C++. They also later advertise [24] extension of their A -expression library to 
full support for HASKELL. None of their works are unfortunately available online for 
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experimentation. We can therefore not evaluate their works any further. 4 Sinkovics [ ] 
offers a restricted solution for emulating let-bindings in template metaprogramming. 

Milewski [9] has a number of posts on his personal blog that speak about Monads 
[ ], their benefits for C++, and how to implement Monadic entities in C++. He also 
has a post on how template metaprogramming with the newly added C++ construct 
variadic templates is similar to lazy list processing in HASKELL. Finally, Sankel [ ] 
shows how to implement algebraic datatypes in C++. 

3 Preliminaries 

Templates were originally to enable compile-time genericity by type [4, §2.2] in C++, 
which, in crude terms, is compile-time code reuse for every type. The st ruct S (line 1 
below), for example, is meant to work for every type Tl and T2. Likewise, function f 
(line 2 below) is meant to work for every type T: 

i template <typename Tl, typename T2> struct S {typedef ... type;}; 

2 template <typename T> void f(T) {...} 

3 template<typename T> struct S<T, int> {...}; 

4 templateo void f (float) {...} 

5 template<int n> class C {typedef typename S<...>::type type}; 

Templates can be specialised for types implementations of which may differ from 
the general one. (See the above lines 3 and 4 for the syntax.) Pattern matching is used to 
choose between the available implementations. Yet, C++ always chooses the best-match 
in pattern matching, whilst in many FP languages including HASKELL, the earliest 
match is always chosen. Templatisation can be over compile-time integral constants too 
(such as class C above) for which specialisation is also allowed. 

Templates can have nested types/values. For example, the structure S above defines 
type as a nested type. When a compiler fails to infer whether a token is a nested type 
or other sorts of nested entity, use of the keyword typename informs the compiler that a 
nested type is the intention. (See line 5 above for example.) 

MPL [ ] is the metaprogramming component of the Boost C++ library. We use the 
following items from MPL, which we explain very briefly: 

- integral_c<T, n> is a type representation for a compile-time constant n of integral 
type T. 

- bool_<b> is a type representation for the compile-time Boolean constant b. bool_<> 
uses true_ and false, as its compile-time equivalents for true and false. 

- not_<T>: :type is a type representing the Boolean complement of the one repre- 
sented by T. 

- if_c<b, Tl, T2>: : type is equivalent to Tl if b is true, and to T2 otherwise. 

An FP language which does not allow side-effects is called a pure FP language. 
When an argument is only evaluated if needed and the result of evaluation is shared 
thereafter in the scope, the variable is said to be evaluated lazily [ ']. 



4 Through personal email exchange, we were informed that they are elaborating on their devel- 
opments. The result is to be placed online for experimentation. 
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4 Compile-Time Rational Numbers 

This section starts by discussing how to implement the auxiliary functions needed. It 
then explains how to represent Q itself in C++ and HASKELL. Finally, it explores the 
implementation techniques we use for supporting operations on Q in either language. 

Throughout this section, we run a comparative study of the implementation tech- 
niques used across the two languages. With this study of commonalities and differences, 
we discuss the impediments to automatic translation between C++MP and HASKELL. 

4.1 Greatest Common Divisor 

Fraction cancellation is the cornerstone of any arithmetic on Q - that is, dividing the 
nominator and denominator by their greatest common divisor (gcd). The metafunction 
implementation of gcd using Euclid's famous algorithm is a straightforward pattern 
matching - the first FP technique used in C++MP that we present: 

i template<long unsigned a, long unsigned t» 

2 struct GCD {const static long unsigned value = GCD<b, a % b>: : value; } ; 

3 template<long unsigned a> 

4 struct GCD<a : 0> {const static long unsigned value = a;}; 

This is one of the very few examples where the mathematical definition of an oper- 
ation is not far from its C++ metafunction implementation. The HASKELL implementa- 
tion is even better and is literally identical to Euclid's algorithm. Both implementations 
use tail recursion, obviously on immutable data: 

i gcd a = a 

2 gcd a b = gcd b (a 'mod' b) 

An important difference between C++ and HASKELL here is that, in C++, the gen- 
eral definition of a template needs to be introduced first. Only then can the specialisa- 
tions come but their relevant order of definition is not significant so long as they are in 
scope. In HASKELL, however, the order of pattern matches is significant and that does 
include the general case. Here, for instance, the general case needs to come after the 
case for gcd(a, 0), or the recursion will never end. 

We use the following example to demonstrate the significance of this difference in 
action when considering automatic translation. Let us suppose - for the sake of argu- 
ment - that gcd(0,a) = 0. In order to accommodate that, one would need to also provide 
the following two specialisations for the C++ metafunction: 

i template<long unsigned a> 

2 struct GCD<0 : a>{const static long unsigned value = 0;}; 

3 

4 templateo struct GCD<0, 0> {const static long unsigned value = 0;}; 

and the order of the template specialisations is not relevant because all the in-scope 
specialisations will be equally visible at the instantiation time. On the other hand, for the 
Haskell counterpart, the following two lines would have needed to be added before 
the general case, for HASKELL always goes for the first pattern match: 
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i gcd a = 
2 gcd 0=0 



As discussed in Section 4.3, this subtle difference can under certain circumstances 
cause compilation failures upon automatic translation from HASKELL to C++. How- 
ever, as far as the relative order of definitions is the concern, the real notoriety faced for 
such a translation is right here. Consider a translation from C++ to HASKELL which 
naively adds the two new gcd cases after the existing cases, and in particular, after 
the general case: No error/warning messages may be emitted in either language; both 
implementations are furthermore logically correct; yet, the subtle difference between 
languages entails observing different results. The reason will be arduous to spot and is 
likely to cater a full genre of implementation bugs. Automatic translation from C++ to 
Haskell will be even trickier for the correct order of patterns needs to be figured out. 



4.2 Representing Rational Numbers 

For a compile-time representation of Q, the nominator and denominator need to be 
stored as template parameters. Note that C++ template metaprograms are pure func- 
tional entities. As a result, the passed template arguments cannot be mutated, and the 
cancelled nominator and denominator have to be stored as nested values/types. We 
choose to represent those using types to avoid possible linkage failures: 

i template<long unsigned p, long unsigned q = 1, bool negative = false> 

2 struct Rational 

3 { 

4 B00ST_STATIC_ASSERT((q !=0)); 

5 const static long unsigned gcd = GCD<p, q>::value; 

(, typedef mpl : : integral_c<long unsigned, p / gcd> num_t; 
7 typedef mpl : : integral_c<long unsigned, q / gcd> den_t; 

8 

9 static string to_string() 

u> { 

u return p? 

12 ( 

13 (negative? "-": "") + 

14 lexical_cast<string>(num_t :: value) + 

15 (den_t :: value == 1?"": "/" + lexical_cast<string>(den_t :: value) ) 



"0"; 



i» } 

.9 }; 



In order to give equal range to the nominator and denominator, we use unsigned 
types for both. That entails storing the sign of a fraction in a separate Boolean template 
parameter (negative). 5 On the other hand, in HASKELL, data structures are represented 
using algebraic datatypes: 



5 Had we chosen the nominator to carry the sign of the fraction by making it signed, the nomi- 
nator's maximum absolute value was enforced to be half that of the denominator. 
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i data Fraction = Fraction Word Word Bool 
2 Fraction _ _ = undefined 



The first important difference between the C++ version and the HASKELL one is 
right in how they deal with partially defined datatypes. In C++, one usually employs 
static assertion to outlaw undefined instantiations. (See the use of BOOST_STATIC_ASSERT 
at line 4 in the definition of Rational.) Such a mechanism is not present in HASKELL, 
so for example, line 2 in the definition of Fraction will not prevent its use with as the 
denominator. HASKELL however does support partial definition of functions. Thus, one 
way to circumvent this problem is to encapsulate the outlawing in a pivotal function: 

i cancel (Fraction _ _) = undefined 

2 cancel (Fraction p q n) = Fraction (p 'div' g) (q 'div' g) n 

3 where g = gcd p q 

Note that, in the C++ version, default values are provided for the denominator and 
sign, whereas that is not possible in HASKELL. Furthermore, because HASKELL does 
not support OOP, there is no way to store the cancelled nominators and denominators 
in the body of the type Fraction. Likewise, in HASKELL, one may go about string 
representation of a fraction as follows - again, not encapsulated in Fraction: 

i instance Show Fraction where 

2 show = show' . cancel where 

3 show' (Fraction _ _) = "0" 

4 show' (Fraction p q n) = (if n then "-" else "") ++ 

5 show p ++ (if q == 1 then "" else "/" ++ show q) 

The routine string representation is similar in C++ and HASKELL: A 0-nominator 
fraction is always written as "0" with no sign; when the denominator of a fraction is 
"1", only the nominator is written; the sign is only written if the fraction is negative. 

Due to the lack of local storage in HASKELL, the pattern of cancelling fractions be- 
fore arithmetic operations will occur repeatedly. Obviously, this on-the-fly cancellation 
is unacceptable in C++ where efficiency is critical. Cancellation is an example of when, 
in the translation from HASKELL to C++, one would need to encapsulate the function- 
ality in a (data) member for efficiency reasons. We anticipate that figuring out when 
similar encapsulations are needed is a highly non-trivial task for automatic translation, 
let alone the correct encapsulation. 

In C++, the detachment of the string representation from the Rational class is con- 
sidered inappropriate because that would be unreasonably scattered. Therefore, an au- 
tomatic translation from HASKELL to C++ would need to be able to infer when to 
encapsulate such a function in the class. Likewise, because this encapsulation is not 
directly possible in HASKELL, one needs to detach similar member functions upon an 
automatic translation from C++ to HASKELL. 

We finish this subsection by two basic functions which will be handy later: 

i num (Fraction p _ _) = p 
2 den (Fraction _ q _) = q 
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4.3 Operations 

C++ was never specifically designed to be a language for metaprogramming. A conse- 
quence is that metafunctions do not come with a built-in return mechanism. Hence, one 
needs to specify the deliverables using named nested types/values. We did already see 
the use of nested values for returning the value of a gcd. Here, we are going to use a 
type to represent the result of an operation on Q: 

i template-:. . .> struct Plus{typedef Rationale. . .> result;}; 

An automatic translation from HASKELL to C++ needs to be particularly careful on 
whether to map a given value to a nested value or a nested type. 



Reducing Repetition Using Preprocessor Metaprogramming. Having to specify de- 
liverables using nested entities makes dealing with expression combination very labour- 
ing. For example, if we choose to implement plus like 

i template<long unsigned pi, long unsigned ql, bool nl, 

2 long unsigned p2, long unsigned q2, bool n2> struct Plus {...}; 

there will be no way to perform operations like Plus<Plus<. . .>, . . .>. The reason is 
that Plus<. . .> is not a Rational itself- its result nested type is. To circumvent this 
problem, one would provide a general case where both template parameters are arbitrary 
types (with particular nested types). One would then append that by the appropriate 
number of template specialisations. 

In our case, for example, one would provide a general template<typename Tl, 
typename T2> struct Plus in addition to specialisations for Plus<Tl, Rational<p2, 
q2, n2> >, Plus<Rational<pl, ql, nl>, T2>, and Plus<Rational<. ..>, Rational 
< . . . > >. The trick is that, for all cases, when the template parameter is not a Rational, 
one forwards the operation to the respective result nested type. The real calcula- 
tion happens only in the Plus<Rational<. . .>, Rational-;. . .> > case. This repetitive 
nested-entity forwarding will occur for all the Q operations and C++ programmers often 
evade similar manual implementations using preprocessor metaprogramming: 

i #define OP_INIT_TEMPLATES( r, NestedType, OpName) \ 

2 template<typename Tl, typename T2> \ 

3 struct OpName \ 

4 { \ 
s typedef typename OpName<typename Tl: : NestedType, \ 

6 typename T2 ; :NestedType>: : NestedType NestedType ;\ 

7 }; \ 

s template<typename Tl, long unsigned p2, long unsigned q2, bool n2>\ 
9 struct OpName<Tl, Rational<p2, q2, n2> > \ 
io { \ 

n typedef typename OpName<typename Tl: :NestedType,\ 

12 Rational<p2, q2, n2> >: :NestedType NestedType;\ 

13 }; \ 

14 template<long unsigned pi, long unsigned ql, bool nl, typename T2>\ 
is struct OpName<Rational<pl, ql, nl>, T2> \ 

16 { \ 

17 typedef typename OpName<Rational<pl, ql, nl>, \ 
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is typename T2 : :NestedType>: :NestedType NestedType;\ 

.9 }; 

20 #define RATIONAL_ARITHMETIC_OPS (Multiplies, (Plus, (Minus, B00ST_PP_NIL) ) ) 
2i #define RATIONAL_COMPARATIVE_OPS (Less, (EqualTo, B00ST_PP_NIL) ) 

22 BOOST_PP_LIST_FOR_EACH(OP_INIT_TEMPLATES, result, RATIONAL_ARITHMETIC_OPS) 

23 BOOST_PP_LIST_FOR_EACH(OP_INIT_TEMPLATES, type, RATIONAL_COMPARATIVE_OPS) 

Here is a quick explanation on how that is particularly related to FP: Note first that 
the list of operation names (RATI0NAL_ARITHMETIC_0PS and RATIONAL. C0MPARATIVE_0PS) 
are constructed in exactly the same way as one would construct a list using the familiar 
cons operator in FP. Next, one needs to note that B00ST_PP_LIST_F0R_EACH is in fact 
the preprocessor equivalent of the famous map function in FP. 

Given that HASKELL functions do already have built-in support for specifying de- 
liverables, this entire code bloat is redundant when it comes to translation from C++MP 
to HASKELL. Figuring that out does not seem to be an easy task for automatic transla- 
tion. The other translation direction is in fact not needed to generate the preprocessor 
portion because a machine can generate all classes themselves without getting bored. 
Yet, the translator needs to know that this code bloat is indeed needed for metafunctions 
enforce nested-entity forwarding. 

In sizeable industrial projects where C++MP is needed, a careful mixture of tem- 
plate and preprocessor metaprogramming is often unavoidable. In such cases, deciding 
on how to deal with each part of the mixture is yet another non-trivial task for automatic 
translation. See Section 5 for more. 



Comparatives The general idea to examine equality of two fractions is to examine the 
respective cancelled nominators and denominators whilst also taking the sign into ac- 
count. Special cases can be handled quicker. Two fractions can obviously not be equal 
when they have different signs. However, our cancellation algorithm does not change 
the original sign of a Fraction. There comes a subtle consequence: Although the fol- 
lowing two equations hold for every non-zero q: 

Rational<0, q, false>: : num_t :: value == Rational<0, q, true>: : num_t :: value 
Rational<0, q, false>: :den_t :: value == Rational<0, q, true>: :den_t :: value 
the fractions would still have different signs. A pointwise equality test will therefore not 
quite work. The case for two fractions with different signs needs special care. Let us 
examine the HASKELL implementation first: 

i instance Eq Fraction where 

2 (Fraction _ _) == (Fraction _ _) = True 

3 (Fraction _ _ nl) == (Fraction _ _ n2) | (nl /= n2) = False 

4 fl == f2 = (num fl' == num f2' && den fl' == den f2') where 

5 fl' = cancel fl 

6 f2' = cancel f2 

Because HASKELL always chooses the first successful pattern match, no conflict 
happens between the first two cases. The story is different in C++ though for, in C++, 
there is no relative ordering between the in-scope specialisations. Hence, the follow- 
ing attempt will fail because neither specialisation is a better fit for equality between 
Rational<0, q, true> and Rational<0, q, false>. An ambiguity error message will 
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be emitted for such a comparison attempt. It is noteworthy that an automatic translation 
from the HASKELL version to C++ is also most likely to produce something like: 

i template<long unsigned ql, bool nl, long unsigned q2, bool n2> 

2 struct EqualTo<Rational<0, ql, nl>, Rational<0, q2, n2> > 

3 {typedef mpl::true_ type;}; 

4 

5 template 

6 < 

7 long unsigned pi, long unsigned ql, 

s long unsigned p2, long unsigned q2, bool n 

9 > struct EqualTo<Rational<pl, ql, n>, Rational<p2, q2, ! n> > 

io {typedef mpl::false_ type;}; 

The solution is to merge the two specialisations into one. Expecting an automatic 
translation from HASKELL to C++ to manage this merging technique is not realistic. It 
would be even less expectable for the other direction of automatic translation to sort the 
correct HASKELL ordering out. The case when the two fractions have the same sign is 
routine and we will present all that together: 

i template 

2 < 

3 long unsigned pi, long unsigned ql, 

4 long unsigned p2, long unsigned q2, bool n 

5 > struct EqualTo<Rational<pl, ql, n>, Rational<p2, q2, ! n> > 

6 {typedef typename mpl : : bool_<pl == && p2 == 0> type;}; 

7 

s template 

9 < 

io long unsigned pi, long unsigned ql, 

ii long unsigned p2, long unsigned q2, bool n 

12 > struct EqualTo<Rational<pl, ql, n>, Rational<p2, q2, n> > 

13 { 

14 typedef typename Rational<pl 
is typedef typename Rational<p2 
i6 typedef typename Rational<pl 
n typedef typename Rational<p2 

18 

19 typedef typename mpl:: bool- 



qi, 


n>: 


:num_ 


.t 


numL 


_t 


q2, 


n>: 


:num_ 


_t 


num2_ 


_t 


qi, 


n>: 


:den_ 


.t 


denL 


_t 


q2, 


n>: 


:den_ 


_t 


den2_ 


_t 



numl_t :: value == num2_t :: value && denl_t :: value == den2_t :: value 
> type; 



23 }; 



In HASKELL where Type Classes are available, our definition of == also implements 
/= automatically. Was our Rational class a runtime one, C++ Concepts could have 
likewise been used. Given that Rational is for compile-time use, we would need to 
define a new Concept to be the compile-time counterpart of EqualityComparable. We 
would like to remind that EqualityComparable defines the types and (runtime) functions 
each of its instantiations need to provide. In other words, EqualityComparable does not 
constrain the respective metafunctions of its instantiations. Were we about to go for the 
metaprogramming counterpart of the Eq Type Class of HASKELL, we needed to first 
define the Concept for types with metafunctions providing a type nested-type. Next, 
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we had to define a Concept like MetaEqualityComparable, which states the names of 
the relevant equality metafunctions. We would need to implement NotEqualTo in terms 
of EqualTo in MetaEqualityComparable and state that Rational models it too. The 
definition of EqualTo for Rational would then suffice to get NotEqualTo automatically. 
Alternatively, we can manually define operations in terms of each other without 
resorting to Concepts. Here, we only present how to do that for NotEqualTo in terms of 
EqualTo. Note that in the implementation of Less, similar merge techniques to the ones 
used for EqualTo are needed to avoid ambiguity between template specialisations. 

i template<typename Tl, typename T2> struct NotEqualTo 

2 {typedef typename mpl : :not_<typename EqualTo<Tl, T2>: : type>: : type type;}; 

A note on laziness seems suitable here: We could have chosen to implement the 
operations lazily, say using techniques presented in [2]. For example, we could have 
chosen NotEqualTo to be implemented as: 

i template<typename Tl, typename T2> struct NotEqualTo 

2 {struct apply{typedef typename mpl :: not_<. ..>:: type type;};}; 

The benefit of this technique is that the mere instantiation of NotEqualTo<Tl , T2> 
will not trigger the computation. Instead, NotEqualTo<Tl, T2> can be freely passed 
around with the computation only taking place the first time that NotEqualTo<Tl, 
T2> : : apply : : type is queried. (Note the similarities with the (bind) in Figure 1 .) Whether 
an automatic translation from HASKELL to C++ should by default choose the lazy 
metaprogramming or the strict one can be controversial. See Section 5 for more. 



Arithmetics Arithmetic operations on types are typically expected to at least consist 
of the four basic operations. The metaprogramming techniques used for the implemen- 
tation are mainly similar. So, we only present plus here in which the main FP technique 
used is mutual recursion with minus: 

i template 

2 < 

3 long unsigned pi, long unsigned ql, 

4 long unsigned p2, long unsigned q2, bool n 

5 > struct Plus<Rational<pl, ql, n>, Rational<p2, q2, n> > 
<> { 

7 typedef typename Rational<pl, 

» typedef typename Rational<p2, 

9 typedef typename Rational<pl, 

hi typedef typename Rational<p2, 

ii 

i: typedef Rational 

13 < 

14 numLt :: value * den2_t :: value + num2_t :: value * denl_t :: value, 
is denl_t : :value * den2_t :: value, 
i6 n 

i7 > result; 
.» }; 

19 template 

20 < 



qi, 


n>: 


:num_ 


t 


numL 


_t 


q2, 


n>: 


:num_ 


t 


num2_ 


_t 


qi, 


n>: 


:den_ 


t 


denL 


_t 


q2, 


n>: 


:den_ 


t 


den2_ 


_t 
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21 long unsigned pi, long unsigned ql, 

22 long unsigned p2, long unsigned q2, bool n 

23 > struct Plus<Rational<pl, ql, n>, Rational<p2, q2, ! n> > 



v { 



typedef typename mpl::if_c 

< 
n, 

typename Minus<Rational<p2, q2, !n>, Rational<pl, ql, ! n> >::result, 
typename Minus<Rational<pl, ql, n>, Rational<p2, q2, n> >:: result 

>: : type result; 



3i }; 



Here is a quick recap: 

- When pi/qi and pi/qi both have a sign n, we first acquire the respective can- 
celled fractions through the nested types. Let us call them p\/q\ and p^/q^, re- 
spectively. (Note that these are already calculated at the instantiation time.) The 

result is Pl q } p } <?1 with sign n. 

- Otherwise, the operation will transform to a subtraction. The resulting fraction has 
the same sign as that of the first fraction when that is negative. It takes the opposite 
sign otherwise. We would need to subtract pi/qifrom pi/qi in the latter case. 

Perhaps the only syntactic difference between the C++ metaprogram and the HASKELL 
program is the use of guards in the HASKELL one in contrast to the use of inline oper- 
ations. This is because in HASKELL in order to test whether the two fractions have the 
same sign or not, we cannot repeat the sign token in the pattern whereas this is fine in 
C++. So long as the guard conditions are simple, an automatic translation should not 
face much difficulty. Yet, complicated guards might need a separate treatment. Despite 
all that, the two codes are so similar that one could simply rewrite one with the other 
syntax to got to the other implementation. 

i plus (Fraction pl ql nl) (Fraction p2 q2 n2) | nl == n2 = 

2 cancel (Fraction (numl * den2 + num2 * denl) (denl * den2) nl) where 

3 fl = cancel (Fraction pl ql nl) 

4 f2 = cancel (Fraction p2 q2 n2) 

5 numl = num fl 

6 num2 = num f2 

7 denl = den fl 
s den2 = den f2 

s plus (Fraction pl ql nl) (Fraction p2 q2 n2) | nl /= n2 = 
io cancel raw_ result where 
ii raw_ result = if nl 

12 then minus (Fraction p2 q2 n2) (Fraction pl ql n2) 

13 else minus (Fraction pl ql nl) (Fraction p2 q2 nl) 

The subtle difference is that, for better efficiency in the HASKELL version, one 
would apply a final cancellation to raw_ result when n\ ^ «2- However, this is not 
needed in the C++ version for the cancelled nominators and denominators will be au- 
tomatically stored upon instantiation. In this very case, automatic translation might not 
be expected to be able to handle this subtle difference. In larger applications, however, 
real performance hits upon translation can source from similar subtle differences. 



3> 


rlt; 




3, 


true> 


r2t; 


3> 


r3t; 
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, true> r4t; 


5> 


r5t; 






r5t>: : 


result 


e< 


r4t>: : 


result 
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Samples Complicated arithmetic expressions can now be evaluated using our libraries. 

i typedef Rational<2, 

2 typedef Rational<l, 

3 typedef Rational<5, 

4 typedef Rational<10, 

5 typedef Rational<3, 

6 typedef LessEqual 

7 < 

8 Plus<Multiplies<r4t , r5t>: : result , Negate<r2t>: : result>: : result , 

9 Minus<Divides<Negate<r4t>: : result , rlt>: : result , r3t>:: result 
io >: : type result; 

Note that all computations are compile-time. The corresponding runtime HASKELL is: 

i rl = Fraction 2 3 False 

2 r2 = Fraction 1 3 True 

3 r3 = Fraction 5 3 False 
t r4 = Fraction 10 9 True 

5 r5 = Fraction 3 5 False 

6 result = 

7 (plus (multiplies r4 r5) (neg r2)) < (minus (divides (neg r4) rl) r3) 



5 Conclusion 

In this paper, we show how close C++MP is to FP - a fact known for a long time but 
never well presented. We implement a C++ compile-time abstract datatype for <Q which 
closely corresponds to its HASKELL runtime counterpart. As also shown in this paper, 
despite the remarkable proximity in the techniques, the HASKELL syntax by far out- 
performs. Earlier research therefore suggests starting from the HASKELL programs as 
a design phase and moving to C++MP as the implementation. The idea is that work- 
ing with the neat syntax of HASKELL is much easier than C++MP, especially for C++ 
templates are known to be notoriously unapproachable when it comes to error/warning 
messages. Yet, it is worth noting that software development typically entails several it- 
erations between design and implementation before each release. The ability of going 
back and forth between the design (HASKELL programs in this case) and the implemen- 
tation (C++ metaprograms in this case) here becomes vital. We argue therefore that any 
mechanical translation across the two languages needs to be bidirectional. 

With this mindset, alongside the codes that we present in this paper, we consider 
translations both from HASKELL to C++ and vice versa. We study commonalities which 
pave the way for mechanical translations, as well as differences as the hindrances on 
the way. We show how pattern matching, tail recursion, and immutability is closely 
similar across HASKELL and C++MP Figure 2 summarises the impediments caused by 
the differences enumerated in this paper. Along with the section visited in, it comments 
on the feasibility of overcoming each impediment. Here is a row-by-row discussion: 

1. The general case should be moved to the top from HASKELL to C++, and to the 
bottom in the opposite direction of translation. The correct ordering for HASKELL 
should be provided by the user for the first time and should be retained for further 
back and forth translation so long as the user does not change it. 
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first pattern match chosen 
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Sol = Solution, S = Semi-Automatically Possible, C = Circumventable, N/C = No Correspondent 



Fig. 2. Mechanical Translation between Haskell and C++MP 



2. From C++ to HASKELL, one needs to resort to partially defined functions with piv- 

otal role, if any. The translation needs to be instructed about the static assertion 
being artificially encapsulated in a function in the HASKELL equivalent. 

3. From HASKELL to C++, the translation should be instructed about the functions to 

be packed together in an abstract datatype. In the other direction, each member 
function will be translated to a stand-alone function. 

5. From C++ to HASKELL, functions which perform the stored calculation should be 

contrived to be used on-the-fly every time the compile-time data member is used 
in the C++ version. The translator needs to be instructed about this correspondence 
between the data members and functions for next translation iterations. 

6. Use named nested entities in C++. The translator should be instructed not to translate 

these entities into HASKELL. 

7. From HASKELL to C++, the user needs to manually advise the translator about each 

entity being translated into a nested value or a nested type. From C++ to HASKELL, 
every nested entity is translated into a HASKELL value. 

8. If possible, from C++ to HASKELL, the user needs to manually instruct which parts 

of this mix to dismiss upon translation. From HASKELL to C++, the translator needs 
not to update the dismissed parts. Note that, in many cases, this dismissal might not 
be possible or very tricky to specify. See the supplementary notes below. 

9. When upon the translation from HASKELL to C++ a compile error is emitted due 

this difference, use the merge technique presented in this paper or similar ones in 
C++. Usages of these techniques need to be marked for the translator to know not 
to touch the manually corrected translations until there is a change in the HASKELL 
version. Refer to guideline 1 for retaining the order of specialisations. 

This paper makes it obvious that full mechanical translation between HASKELL 
programs and C++ metaprograms is not realistic. Nevertheless, Figure 2 and the above 
discussion do indeed suggest the approachability of semi-automatic translation. In or- 
der to incarnate that, one might be intrigued to try simulating features of one language 
in the other one. We would like to remind, however, that the whole point of resort- 
ing to Haskell is to harness the spontaneity of C++MP's syntax for FP purposes. In 
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other words, the syntax of C++MP is already exotic enough to make C++ programmers 
practice a variety of non-trivial indirections. Adding extra layers of indirection on top 
of that for the purpose of emulating HASKELL would defeat the purpose by entailing 
extra syntactic chaos. Likewise, because HASKELL is designed to be uniparadigm, 
emulating say OOP often produces very unnatural HASKELL codes. 

F# is a strict FP language with selective laziness. Moreover, impediments 2 to 5 of 
Figure 2 will not be faced upon translation between C++MP and F#. This is because 
F# supports OOP too and one can employ: exceptions thrown in F# constructors for 
the second one; F#'s built-in object encapsulation for the third; abstract datatypes with 
multiple constructors for the forth; and, ordinary data members for F# abstract datatypes 
for the fifth impediment. Fully removing impediment 8 on mixed template/preprocessor 
metaprogramming can still be considerably demanding for F# too. Here is an instance 
of where in the industry one of the authors needed to use such a mixture: Consider a 
C++ struct S templatised by an integer and with a function call operator which, for every 
n, invokes a function f for the first n elements of an array a: 

i #define DUMMY_INDEXER(z, n, data) data[n] 

2 #define CALL_WRAPPER_MACRO(z , n, unused) \ 

3 templateo struct S<n> \ 
* { \ 

5 template<typename Array> double operator () (const Array& a)\ 

6 {return f (B00ST_PP_ENUM(n, DUMMY_INDEXER, a));} \ 

7 }; 

Our final remark is that, although F# is a better match for facilitating C++MP by 
leveraging its FP nature, the best option is perhaps to design a new FP language with 
built-in correspondent FP features as that of C++MP This is because: real-world C++ 
is often full of such complex mixtures; C++MP combines laziness and strictness in un- 
usual ways that do not fully correspond to any available FP language; pattern matching 
in C++ uses the best match strategy as opposed to the common first match of FP; and, 
there is no point in trying to emulate the other language's features for better translation. 
A successful such language can then eventually become a part of the C++ tool chain. 
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